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REMARKS 

These Remarks are in reply to the Office Action mailed June 16 T 2004. 

I. Status of Claims 

Claims 1-30 were pending in the Application prior to the outstanding Office Action, with 
claims 1,9, 13, 17 and 24 being independent. No claims are being presently amended, added or 
canceled, leaving for the Examiner's present consideration claims 1-30. 

II. 35 U.S.C. 101 Rejections 

Applicants would like to thank the Examiner for withdrawing the 35 US.C. 101 
rejections of claims 1-16 and 24-30. 

III. 35 U.S.C. 102(e) Rejections 

Claims 1-30 were again rejected under 35 U.S.C 1 02(e) as allegedly being anticipated by 
U.S. Patent No. 6,549,936 to Hirabayashi (hereafter referred to simply as "Hirabayashi"). 

Applicants' remarks in response to this rejection begin on the next page. Reconsideration 
of this rejection is respectfully requested. 
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A. Claims 1-8 

Claim 1 is reproduced below for the convenience of the Examiner. 

1. (Original): A job management apparatus for use in a batch job execution 
system including a plurality of service providers in communication with the job 
management apparatus, the apparatus comprising: 

a client communications part which receives a batch job from a client; 
an extracting part which extracts a task from the batch job; and, 
an assigning part which receives a first signal from at least one of the 
plurality of service providers, and in response to the first signal delegates the task 
to one of the plurality of service providers for performing the task. 

As Applicants* have previously pointed out, claim 1 includes "an assigning part which 

receives a first signal from at least one of the plurality of service providers, and m response to 

the first signal delegates the task to one of the plurality of service providers for performing the 

task" (emphasis added). In the arguments filed April 1, 2004, Applicants asserted that the 

gateway of Hirabayashi does not delegate a task in response to a first signal received from at 

least one of the plurality of service provides. The present Office Action says that the Examiner 

disagreed with Applicants 1 arguments for the following reasons: 

"Per (a), Hirabayashi discloses in FIG. 2 and col. 6, lines 53-65 that the 
server gateway 203 transfers (i.e., delegates) the request to the corresponding 
server 204 (i.e., service provider). Although Hirabayashi does not specifically 
disclose the first signal (i.e., an acknowledgement signal), a first signal must exist 
in order to provide an acknowledgment from server 204 to the gateway server 
203 to proceed with the transfer/' (See Office Action of 06/16/2004, Page 14 s 1st 
paragraph). 
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In the Office Action it is admitted that Hirabayashi does not specifically disclose that the 
gateway 203 of Hirabayshi receives a first signal. However, the Examiner asserts that a first 
signal must exist in order to provide an acknowledgement from the server 204 to the gateway 
203 to proceed with the transfer. Applicants do not necessarily agree with this assertion. 
However, even assuming the Examiner's assertion is correct, for the following reasons 
Applicants still believe that Hirbayashi does not teach the invention of claim 1 . 

Applicants would like to first point out that term "delegates" in claim 1 means "assigns". 
Thus, when the assigning part of claim 1 (in response to the first signal) "delegates" the task to 
one of the plurality of service providers, the assigning part actually assigns the task to one of the 
service provides in response to the first signal. Applicants point this out because it appears that 
the Examiner has interpreted the term "delegates" to mean the same thing as "transfers," which it 
does not. Rather, the term "transfers" means to move from one place to another. While it is 
possible that the assigning part of claim 1 may transfer a task after it delegates a task, the terms 
"delegates" and "transfers" are not synonymous. 

Referring now to the language of claim 1, the assigning part specifically receives a first 
signal from at least one of the plurality of service providers, and in response to the first signal 
delegates (i.e., assigns) the task to one of the plurality of service providers for performing the 
task. Thus, there is a specific order in which the "assigning part" of claim 1 performs its 
functions. In other words: prior to delegating a task, the assigning part receives a first signal 
from at least one of the plurality of service providers; then, after receiving the first signal, and in 
response to the first signal, the assigning part delegates the task to one of the plurality of 
service providers for performing the task. In other words, the "assigning part" of claim 1 takes 
into account the "first signal" when it "delegates the task." As explained in the application, the 
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first signal can, e.g., inform the assigning part of the service providers ability to execute a task 
(as recited in claim 3 f discussed below). 

As pointed out in Applicants' Response of April 1, 2004, column 6, lines 53-56 of 
Hirabayashi merely states "The server gateway 203 receives the request block 202 transferred 
from the respective clients and analyzes the request, then judging [sic] to which server the 
request should be transferred/* Even assuming for the sake of argument that the Examiner is 
correct that "a first signal must exist in order to provide an acknowledgement from the server 
204 to the gateway 203 to proceed with the transfer," the server gateway 203 of Hirabayashi still 
does not perform the claimed functions of claim 1 in the claimed order of claim 1, Rather, the 
server gateway 203 receives the request block from a client and analyzes the request. Next, the 
server gateway 203 decides to which server 204 it should delegate the task, without taking into 
account any signal received from service providers. Then (assuming the Examiner is correct), 
the server gateway 203 contacts the server 204 to which it has delegated the task, and the server 
204 sends an acknowledgment to proceed with the transfer. This is quite different from the 
invention of claimed 1 because, as previously pointed out, the server gateway 203 of Hirabayashi 
decides which server 204 should handle a request based solely on the gateways own analysis of 
the request, hi contrast, the assigning part of claim 1 first receives a first signal (e.g., a request 
for work) from at least one of the plurality of service providers, and theo, in response to the 
first signal, delegates the task to one of the plurality of service providers for perfoiming the task. 

To summarize, the "assigning part" of claim 1 receives a first signal from one of a 
plurality of service provides, and then, in response to the first signal delegates die task to one 
of the plurality of service providers for performing the task. In contrast (assuming the 
Examiners 1 assertions regarding the use of an acknowledgement is correct), the server gateway 
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203 of Hirabayashi delegates a task to a server 204 (this delegation is not in response to a first 
signal received from one on a plurality of servers), and then, after receiving an acknowledgment 
from the server 204 (indicating the server 204 can accept transfer of the task), the server gateway 

203 transfers the task to the server 204. For at least these reasons, Applicants respectfully 
request that the 35 U.S.C 102(e) rejection of claim 1, and its dependent claims 2-8, be 
withdrawn. 

Claims 2-8 are believed to be patentable for at least the reason that they depend from 
patentable claim 1, as well as for the additional features that they add to claim 1. For example, 
claim 3 specifically requires that "the first signal informs the assigning part of the service 
providers ability to execute a task." It was asserted in the Office Action that column 6, lines 53- 
55 of Hirabayashi teach this feature. However, this portion of Hirabayshi merely states that "the 
server gateway 203 receives the request block 202 transferred from the respective clients and 
analyzes the request, then judging to which server the request should be transferred." 
Accordingly, as explained above, the server gateway 203 of Hirabayshi decides to which server 

204 it should delegate the task, without taking into account any signal received from service 
providers. Even assuming for arguments sake that the Examiner is correct that a server 204 
sends an acknowledgement that it can accept a transfer of data in response to an inquiry by the 
server gateway 203 (after the server gateway 203 has judged to which server to transfer the 
request), there is absolutely no disclosure that the server gateway 203 of Hirabayashi receives a 
signal from a server 204 informing the server gateway 203 of the servers ability to execute a 
task. Further, there is absolutely no disclosure in Hirabayshi that the server gateway in 
response to receiving a signal (informing the server gateway 203 of the servers ability to execute 
a task) delegates the task to one of the plurality of servers 204. For these additional reasons, 
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Applicants again respectfully request that the 35 U.S.C. 102(e) rejection of claim 3 be 
withdrawn. 

B. Claims 9-12 

Claim 9 is reproduced below for the convenience of the Examiner. 

9. (Original): A batch job execution system for communicating with at least 
one client, comprising: 

a job management apparatus in communication with the clients which 
receives a batch job from a client, extracts a task from the batch job, and assigns 
the task; 

a job database in communication with the job management apparatus 
which stores the batch job; 

a plurality of service providers in communication with the job 
management apparatus which receive the assigned task, perform the task, and 
return a result to the job management apparatus; and, 

at least one provider manager in communication with the job management 
apparatus and in communication with the plurality of service providers which 
monitors the tasks being performed on the service providers and provides status 
information to the job management apparatus. 

As Applicants have previously pointed out, claim 9 requires H at least one provider 
manager in communication with the job management apparatus and in communication with the 
plurality of service providers which monitors the tasks being performed on the service providers 
and provides status information to the job management apparatus." In the arguments filed April 
1, 2004, Applicants asserted that Hirabayashi does not teach "at least one provider manager" that 
monitor tasks being performed on a plurality of service provides, and provides status information 
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to a job management apparatus. The present Office Action says that the Examiner disagreed 

with Applicants' arguments for the following reasons: 

"Per (b), Hirabayashi discloses in Fig. 12, col 11, lines 59 - col 12, line ? 
(a line number for column 12 appears to have been accidentally left out) ihat the 
step of monitoring is done by referring to the Job queue to determine whether or 
not a job exists, is awaiting execution, or is in the course of execution. 
Furthermore, in col 6 t lines 23-26, Hirabayashi discloses inquiring the server 
about the state of the job request in the queue and in col 11, lines 24-58, 
Hirabayashi clearly indicates that the status information is provided to a job 
management apparatus (execution managing unit 924) because the request for 
inquiring in what state the job lies is made to server 920. " (See Office Action of 
06/1 6/2004, Page 14, 2nd paragraph). 

As explained below, Applicants still do not agree that the above mentioned sections of 
Hirabayashi teach "at least one provider manager in communication with the job management 
apparatus and in communication with the plurality of service providers which monitors the tasks 
being performed on the service providers and provides status information to the job management 
apparatus/ as required by claim 9, 

First of all, the claimed "at least one provider manager" (which is part of a "batch 
execution system") is separate from the "at least one client" and is separate from the "plurality of 
service providers" of the batch execution system (but may be associated with the plurality of 
service providers). Second, the claimed "at least one provider manager" is "in cornmunication 
with the plurality of service providers" and "monitors the tasks being performed on the service 
providers." Third, the claimed "at least one provider manager" specifically "provides status 
information to the job management apparatus," wherein "job management apparatus" is separate 
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from the clients and service providers. As will be explained below, Hirabayashi does not teach 
or suggest these features. 

It appears that the Examiner is asserting that the "state display unit 913" of the client 910 
teaches the claimed "at least one provider manager" of claim 9. As explained at column 11, lines 
46-51 of Hirabayashi, "the state display unit 913 [of the client 910] issues, to the request 
analyzing unit 921 in the server 920, a request for job-information acquisition (GET) for 
inquiring in what state the registered job lies at present." Then, as explained at column 1 1, line 
59 - column 12, line 8 of Hirabayashi, the "execution management unit 924 in the server 920 
performs the job-information GET processing" by accessing the "job queue 923" and based on 
the job queue 923 determining whether a job is awaiting execution, in the course of execution, or 
whether the execution of the job has been terminated. Also, ,r by referring back to the log stored 
in the executi on-result storing unit 927, information to be returned back of the content of the log 
is summarized as the response data, then being returned back to the state display unit 913 [of the 
client 910]." For the following reasons, this is quite different than the "at least one provider 
manager" of claim 9. 

First of all, in Hirabayashi it is the "state display unit 913" of the client 910 that 
specifically inquires about the state of a job. In contrast, in claim 9 it is the "at least one provider 
manger" that monitors the tasks being performed on the service providers, wherein "the provider 
manager" is separate from the clients and the service providers (see claim 9 and FIGS. 1 & 2 of 
the present application). 

Second, in Hirabayashi the state display unit 913 of the client 910 inquires directly with a 
specific server 920 about the state of a job. In contrast, the "at least one provider manager" of 
claim 9 (which is separate from the clients and the service providers) is "in communication with 
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the plurality of service providers" and "monitors the tasks being performed on the service 
providers." That is, in claim 9 it is not the client that inquires about or monitors tasks being 
performed on the service providers. 

Third, in Hirabayashi, it is the server 920 that provides data regarding the state of a job 
back to the state display unit 913 of the client 910. In contrast, it is the "at least one provider 
manager" of claim 9 that "provides status information to the job management apparatus," 
wherein "job management apparatus" is separate from the clients and service providers (see 
claim 9 and FIGS. 1 & 2 of the present application). That is, in claim 9 the service providers are 
not proving status information; and in claim 9 a client is not the recipient of status information. 
Rather, in claim 9 it is the, "at least one provider manager" that obtains status information, and it 
is the "job management apparatus" that receives that status information from the "provider 
manager/' 

For at least the reasons explained above, Applicants respectfully request that the 35 
U.S.C 102(e) rejection of claim 9, and its dependent claims 10-1 2 7 be withdrawn. 

Claims 10-12 are believed to be patentable for at least the reason that they depend from 
patentable claim 9, as well as for the additional features that they add to claim 9. For example, 
claim 11 specifically requires that "if the service provider fails to complete the task within a 
predetermined time, the provider manager communicates with the service provider, and informs 
the job management apparatus of the task status in response to the communication with the 
service provider." It was asserted in the Office Action that the state display unit 9L3 of the client 
910 teaches these features. However, as explained above, the claimed "provider manager" is 
separate from the clients (i.e., is not part of a client). Additionally, there is nothing in 
Hirabayashi that teaches or suggests that the state display unit 913 is informed of a task status 
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specifically "if the service provider fails to complete the task within a predetermined time. ,, For 
these additional reasons, Applicants again respectfully request that the 35 U.S.C. 102(e) rejection 
of claim 1 1 be withdrawn. 

C Claims 13-16 

Claim 13 is directed to a system for executing a batch job including a plurality of tasks, 
with the system including an "assigning part configured to delegate one of the tasks to one of the 
first and second service providers responsive to receiving the first and second signals from the 
service providers." Applicants respectfully assert that claim 1 3, and its dependent claims 14-16, 
are patentable over Hirabayashi for at least the reasons discussed above with reference to claims 
1-8. 

D. Claims 17-23 

Claim 17 is directed to a method for preparing and executing a batch job by a batch job 
execution system. The method includes the steps of "receiving a first signal from at least one of 
a plurality of service providers which informs the job management apparatus of the service 
providers ability to perform a task" and "delegating the task to the service providers in response 
to the first signal." Applicants respectfully assert that claim 17, and its dependent claims 18-23, 
are patentable over Hirabayashi for at least the reasons discussed above with reference to claims 
1-8. 
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TL Claims 24-30 

Claim 24, as amended, i$ directed to an article of manufacture including an information 
storage medium wherein is stored computer readable information. This comprises, among other 
components "an assigning software component which receives a first signal from at least one of a 
plurality of service providers, and in response to the first signal delegates a task to one of the 
plurality of service providers for performing the task." Applicants respectfully assert that claim 
24, and its dependent claims 25-30, are patentable over Hirabayashi for at least the reasons 
discussed above with reference to claims 1-8. 

IV. Conclusion 

In light of the above, it is respectfully submitted that all of the claims now pending in the 
subject patent application should be allowable, and a Notice of Allowance is requested. The 
Examiner is respectfully requested to telephone the undersigned if he can assist in any way in 
expediting issuance of a patent. 

The Commissioner is authorized to charge any underpayment or credit any overpayment 
to Deposit Account No. 24-0037 for any matter in connection with this response, including any 
fee for extension of time, which may be required. 



Respectfully submitted, 





Jeffrey R. Kurin 
Reg. No. 41 ,132 



FLIESLER MEYER LLP 
Four Embarcadero Center, Fourth Floor 
San Francisco, California 941 1 1-4156 
Telephone: (415) 362-3800 
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